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(57) In accordance with certain aspects of the 
present invention, improved methods and arrange- 
ments are provided that improve access control within 
a computer. The methods and arrangements specifical- 
ly Identify the authentication mechanism/mechanisms, 
and/or characteristics thereof, that were used in verify- 
ing that a user with a unique name is the actual user that 
the name implies, to subsequently operating security 
mechanisms. Thus, differentiating user requests based 
on this additional information provides additional con- 
trol. 
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Description 

[0001] This invention relates to computers and com- 
puter networks, and more particularly to methods and 

arrangements for use In controlling access to various 
resources therein based on authentication methods. 

BACKGROUND 

[0002] In the past, executable content could only be 
installed on a computer system by physically bringing 
magnetic media to the computer and having a user with 
the applicable privileges (e.g., administrative privileges) 
install it. At present, however, the Intemet, intranets, 
wide area networks (WANs), local area networks 
(LANs), etc., make It very easy for ordinary computer 
users to download executable content, such as, e.g., 
ActiveX® controls, programs, and scripts. In many cas- 
es, executable content may be downloaded and execut- 
ed via the Internet without the user even realizing that 
such an event has occurred. 
[0003] Unfortunately, every so often such executable 
content intentionally or unintentionally destabilizes the 
client machine in some manner. For example, the con- 
tent may prove to be error-prone and cause the client 
machine to crash. The content may also undermine the 
security of the client machine by divulging confidential 
information about the client/user. Although these types 
of computer problems have previously existed in the 
form of "viruses" and "trojans," the ubiquitous presence 
of World Wide Web (WWW) portion of the Internet has 
made these problems even more widespread. In gener- 
al, the operating environment of most clients is not ad- 
equately protected against such unruly code. 
[0004] Some operating systems already have an ex- 
isting security mechanism that limits what non-privi- 
leged users may do. For example, the security system 
built into the Windows® NT operating system controls 
access to resources based on the identities of users. 
When a Windows NT process wishes to access a re- 
source to perform some action, the security mechanism 
in Windows NT compares a client's user and group IDs 
and privileges associated with that process against se- 
curity information assigned to that resource to grant or 
deny access to the resource. In this manner, unauthor- 
ized users are prevented from accessing resources and 
potentially causing harm, while authorized users may be 
limited in the actions they are allowed to perform. 
[0005] There are many different authentication meth- 
ods available for use in the client operating system. By 
way of example, a client can select among Kerberos, 
NTLM, Digest, Secure Socket Layer (SSL) or others that 
are available within the operating system. Each of these 
protocols is different; the differences produce varying 
levels of assurance as to the identity of the principals 
involved. Those skilled In the art will appreciate the dif- 
ference between a high-assurance method such as bi- 
ometric authentication, and a lower assurance scheme 



2 

such as a password. 

[0006] Because the eventual end-users or adminis- 
trators of a computer operating system must manage 
access to data, protect their resources against abuse, 

5 and other tasks, these are the appropriate people to de- 
cide what assurance they require for varying tasks. 
Viewing a web page, as an example, may be low value 
enough to allow use of a low-assurance method such 
as a password. Updating company financial information 

10 may require a higher assurance method such as SSL. 
Clearly, the benefit of a consistent method, across a va- 
riety of possible applications, for controlling access 
would be substantial. 

[0007] Hence, there is a continuing need for improved 

15 methods and arrangements for controlling access to 
various networked servers, devices, services, applica- 
tions, etc.. especially in the Internet/intranet networking 
arena. 

20 SUIVIMARY 

[0008] In accordance with certain aspects of the 
present invention, improved methods and arrange- 
ments are provided for controlling access to resources 

25 in a computing environment. The methods and arrange- 
ments specifically identify the authentication mecha- 
nism/mechanisms, and/or characteristics thereof, used 
in verifying a user, to subsequently operating security 
mechanisms. Thus, differentiating user requests based 

30 on this additional information provides additional con- 
trol, 

[0009] By way of example, the above-stated needs 
and others are met by a method for use in a computer 
capable of supporting multiple authentication mecha- 

35 nisms. The method includes generating an operating 
system representation (e.g., a security token, etc) of at 
least one identity indicator, for example, a user or ac- 
count identity, associated with and identifying at least 
one authentication mechanism, and subsequently con- 

40 trolling access to at least one resource based on the op- 
erating system representation. In certain implementa- 
tions, the method further includes generating at least 
one security identifier (SID) that identifies the authenti- 
cation mechanism in some way. for example, by name 

45 or number and/or perhaps by measure of strength such 
as the type/length of an encryption process/key em- 
ployed by the authentication mechanism. In other imple- 
mentations, for example, the method includes compar- 
ing the operating system representation to at least one 

so access control list having at least one access control en- 
try therein. Here, for example, the access control entry 
may operatively specify whether the user authenticated 
by the authentication mechanism is permitted to access 
the resource. 

55 

BRIEF DESCRIPTION OF THE DRAWINGS 

[001 0] A more complete understanding of the various 
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methods and arrangements of the present invention 
may be had by reference to the following detailed de- 
scription when taken in conjunction with the accompa- 
nying drawings wherein: 

Fig. 1 is a block diagram depicting an exemplary 
functional arrangement for controlling access to re- 
sources in accordance with certain implementa- 
tions of the present invention. 
Fig. 2 is a block diagram illustrating an exemplary 
computing environment, suitable for use with the ar- 
rangement in Fig. 1 . 

DETAILED DESCRIPTION 

[001 1 ] Authentication is basically the process of veri- 
fying that a user claiming a unique name or other iden- 
tifier is in fact that user. In the physical world, this is often 
accomplished by using some form of documentation, is- 
sued by a trusted third party such as a government; a 
very common example is a passport. In the computer 
realm, this is often accomplished through an authenti- 
cation protocol. Authorization is the determination of 
what a particular user or other principal Is allowed to do. 
Authorization can take the form of limits, e.g. a credit 
limit on a credit card, or access controls, or, e.g. limiting 
what areas of a building an employee is allowed to enter. 
Authentication and authorization are inter-related, but 
are often analyzed, and even implemented, quite sepa- 
rately. 

[0012] Two common forms of authorization within a 
typical computer system are name-based and identity- 
based. Name-based authorization essentially uses a 
single identifier, the user name, to manage authorization 
decisions. Many web sites use this form; an example is 
only the user has access to the user's account at a typ- 
ical commercial web site. The other form, identity- 
based, is a richer environment. Here, the operating sys- 
tem maintains the identifier for the user, and possibly 
additional identifiers indicating groups or collections of 
users managed by the administrator, for use by an ap- 
plication. Many UNIX-derived systems expose this as a 
user identifier and a list of group identifiers. Windows® 
NT and Windows® 2000 represent this with a construct 
named an access token, which contains the user Iden- 
tifier, the list of groups, and additional restrictions and/ 
or privileges. 

[0013] Authentication can be accomplished in either 
of two ways. One way is to associate a trustee name 
with a password on the initial connection to the data 
source object. The second and preferred way is to use 
secure access tokens or like operating system repre- 
sentations of some identifying indicator granted by the 
operating system only to authentic users/accounts. 
Here, the access token or like operating system repre- 
sentation includes one or more security identification 
descriptors (SIDs) that can be matched against one or 
more discretionary access control lists (ACLs) or the like 



stored in a data store. 

[001 4] A number of conventional authentication tech- 
niques have been implemented in authentication pack- 
ages. By way of example. Windows NT and Windows 

5 2000 provide support for the Windows NT LAN Manager 
(NTLM). Windows 2000 provides additional support for 
the Kerberos security protocol. Other well-known au- 
thentication techniques include Secure Sockets Layer 
(SSL), Schannel. Passport, etc. Additionally, other pro- 

10 prietary authentication techniques may be implement- 
ed, which are similar. 

[0015] With this in mind, a generic arrangement 100 
is provided in Fig. 1 that is readily adaptable to any sim- 
ilar arrangement. The essential functionality in arrange- 
rs ment 1 00 involves the use of an access token or like 
operating system representation 110 that has been fur- 
ther modified to include information that identifies one 
or more types, features and/or other aspects relating to 
the authentication package or packages that were used 
20 to validate the user/account. This operating system rep- 
resentation 1 1 0 advantageously provides for additional 
granularity in the overall system security model. 
[0016] Thus, with reference to Fig. 1. arrangement 
100 includes a logon function 102 that provides an in- 
25 terface with the user. The user is required to provide (i. 
e., input) a user/account name, password or other user/ 
group identifier, for example. In certain implementa- 
tions. logon function 102 may further interface with logic 
on a smart card or like portable token device. In still other 
30 implementations, biometric Information about/from the 
user may be gathered by logon function 1 02. 
[0017] Logon function 102 outputs user logon infor- 
mation, e.g., name and password (or hash of password) 
to an authentication package 104. Authentication pack- 
35 age 1 04 is configured to authenticate or othenwise vali- 
date that the user (based on the user logon information) 
is the actual user that the name implies. As mentioned, 
there are a number of authentication techniques in use 
today. 

40 [001 8] Authentication package 1 04 may utilize an en- 
coding or encryption scheme that requires a key 1 06. In 
certain Implementations, the trustworthiness of the au- 
thentication technique may be tied to the strength (e.g., 
length) of key 106. This is mentioned because this may 

45 be a security measure that is later reflected in the oper- 
ating system representation 110. Authentication pack- 
age 104 may also call upon one or more other sub-au- 
thentication packages 1 08 to verify the user logon. The 
use of a sub-authentication package 1 08 may also affect 

so the trustworthiness of the authentication technique, and 
as such may be reflected In a resulting operating system 
representation 110. 

[0019] As depicted, authentication package 104 out- 
puts one or more authentication package SIDs 112. 
55 which are provided within an operating system repre- 
sentation 110. In this example, operating system repre- 
sentation 110 is an object that identifies the user/ac- 
count as described below and is permanently attached 
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to the user's/account's processes. 
[0020] Here, operating system representation 1 1 0 in- 
cludes a conventional user SID based on the logon 
name and/or password, etc, and at least one authenti- 
cation package SID 112. Operating system representa- 
tion 110 may further include other attributes such as, e. 
g., one or more group IDs, privileges, etc. 
[0021] By providing an authentication package SID 
112 within operating system representation 110. subse- 
quent security functions will be able to further differen- 
tiate between users/accounts. This benefit and others 
are described below, following an oven^iew of an exem- 
plary security arrangement comprising an object man- 
ager 114, a security mechanism 116 and an ACL 118. 
[0022] When the user's process desires access to an- 
other object it specifies the type of access it desires (e. 
g., obtain read/write access to a file object) and at the 
kernel level provides it's a corresponding operating sys- 
tem representation 110 to an object manager 114. The 
object being sought has a kernel level security descrip- 
tor associated with it that includes ACL 1 1 8. Object man- 
ager 110 causes operating system representation 110 
and ACL 1 1 8 to be provided to security mechanism 1 1 6. 
[0023] Within ACL 118 there is at least one access 
control entry (ACE) 120 that defines certain access 
rights (allowed or denied actions) corresponding to that 
entry. For example, ACE 1 20 may include a type (deny 
or allow) indicator, flags, one or more SIDs and access 
rights in the form of a bitmask wherein each bit corre- 
sponds to a permission (e.g., one bit for read access, 
one for write and so on). 

[0024] As such, security mechanism 116 is able to 
compare the SlD(s) in operating system representation 
110 along with the type of action or actions requested 
by the user's process against the ACE(s) 120 in ACL 
118. If a match is found with an allowed user or group, 
and the type of access desired is allowable for the user 
or group, a handle to the desired object is returned to 
the user's process, otherwise access is denied. 
[0025] With the addition of authentication package 
SID(s) 112, security mechanism 116 may also consider 
the authentication package or mechanism. Thus, for ex- 
ample, a user that was authenticated using NTLM may 
be denied access to the desired object based on a deny 
NTLM authentication ACE 120 in ACL 118, while a an- 
other user who was authenticated with Kerberos is al- 
lowed access to the desired object. Further granularity 
is provided by defining different SIDs 1 1 2 and ACEs 1 20 
based on authentication package 104, sub-authentica- 
tion package 108, key 106, or any combination thereof. 
[0026] Attention is now drawn to Fig. 2, which is a 
block diagram depicting an exemplary computing sys- 
tem 200 suitable with arrangement 100. 
[0027] Computing system 200 is, in this example, in 
the form of a personal computer (PC), however, in other 
examples computing system may take the form of a ded- 
icated server(s), a special-purpose device, an appli- 
ance, a handheld computing device, a mobile telephone 



device, a pager device, etc. 

[0028] As shown, computing system 200 includes a 
processing unit 221 , a system memory 222, and a sys- 
tem bus 223. System bus 223 links together various sys- 

5 tem components including system memory 222 and the 
processing unit 221 . System bus 223 may be any of sev- 
eral types of bus structures including a memory bus or 
memory controller, a peripheral bus, and a local bus us- 
ing any of a variety of bus architectures. System mem- 

10 ory 222 typically includes read only memory (ROM) 224 
and random access memory (RAM) 225. A basic input/ 
output system 226 (BIOS), containing the basic routine 
that helps to transfer information between elements 
within computing system 200, such as during start-up, 

15 is stored in ROM 224. Computing system 200 further 
includes a hard disk drive 227 for reading from and writ- 
ing to a hard disk, not shown, a magnetic disk drive 228 
for reading from or writing to a removable magnetic disk 
229, and an optical disk drive 30 for reading from or writ- 

20 ing to a removable optical disk 231 such as a CD ROM 
or other optical media. Hard disk drive 227, magnetic 
disk drive 228. and optical disk drive 230 are connected 
to system bus 223 by a hard disk drive interface 232, a 
magnetic disk drive interface 233, and an optical drive 

25 Interface 234, respectively. These drives and their as- 
sociated computer-readable media provide nonvolatile 
storage of computer readable instructions, data struc- 
tures, computer programs and other data for computing 
system 200. 

30 [0029] A number of computer programs may be 
stored on the hard disk, magnetic disk 229, optical disk 
231 , ROM 224 or RAM 225, including an operating sys- 
tem 235, one or more application programs 236, other 
programs 237, and program data 238. 

35 [0030] A user may enter commands and information 
into computing system 200 through various input devic- 
es such as a keyboard 240 and pointing device 242 
(such as a mouse). A camera/microphone 255 or other 
like media device capable of capturing or othenA/ise out- 

40 putting real-time data 256 can also be included as an 
input device to computing system 200. The real-time da- 
ta 256 can be input into computing system 200 via an 
appropriate interface 257. Interface 257 can be connect- 
ed to the system bus 223, thereby allowing real-time da- 

45 ta 256 to be stored in RAM 225, or one of the other data 
storage devices, or otherwise processed. 
[0031] As shown, a monitor 247 or other type of dis- 
play device is also connected to the system bus 223 via 
an interface, such as a video adapter 248. In addition to 

50 the monitor, computing system 200 may also include 
other peripheral output devices (not shown), such as 
speakers, printers, etc. 

[0032] Computing system 200 may operate in a net- 
worked environment using logical connections to one or 
55 more remote computers, such as a remote computer 
249. Remote computer 249 may be another personal 
computer, a server, a router, a network PC, a peer de- 
vice or other common network node, and typically tn- 
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eludes many or all of the elements described above rel- 
ative to computing system 200, although only a memory 
storage device 250 has been illustrated in Fig. 2. 
[0033] The logical connections depicted in Fig. 2 in- 
clude a local area network (LAN) 251 and a wide area 
network (WAN) 252, Such networking environments are 
commonplace in offices, enterprise-wide computer net- 
works, Intranets and the Intemet. 
[0034] When used in a LAN networking environment, 
computing system 200 is connected to the local network 
251 through a network interface or adapter 253. When 
used in a WAN networking environment, computing sys- 
tem 200 typically includes a modem 254 or other means 
for establishing communications over the wide area net- 
work 252, such as the Internet. Modem 254, which may 
be internal or external, is connected to system bus 223 
via the serial port interface 246. 
[0035] In a networked environment, computer pro- 
grams depicted relative to the computing system 200, 
or portions thereof, may be stored in the remote memory 
storage device. It will be appreciated that the network 
connections shown are exemplary and other means of 
establishing a communications link between the com- 
puters may be used. 

[0036] Although some preferred embodiments of the 
various methods and arrangements of the present in- 
vention have been illustrated in the accompanying 
Drawings and described in the foregoing Detailed De- 
scription, it will be understood that the invention is not 
limited to the exemplary embodiments disclosed, but is 
capable of numerous rearrangements, modifications 
and substitutions without departing from the spirit of the 
Invention as set forth and defined by the following 
claims. 



with the authentication mechanism. 

4. The method as recited in Claim 3, wherein the at 
least one characteristic associated with the authen- 

5 tication mechanism includes a measure of strength 
of the authentication mechanism. 

5. TTie method as recited in Claim 4, wherein the 
measure of strength of the authentication mecha- 

10 nism identifies a length of an encryption key em- 
ployed by the authentication mechanism. 

6. The method as recited in Claim 1 , wherein control- 
ling access to the resource based on the indicator 

15 further includes comparing the indicator to at least 
one access control list having at least one access 
control entry therein. 

7. The method as recited in Claim 6, wherein if the ac- 
20 cess control entry operatively specifies that the at 

least one authentication mechanism is permitted to 
access the resource, then access to the at least one 
resource Is allowed to proceed. 



25 8. The method as recited in Claim 6, wherein if the ac- 
cess control entry operatively specifies that the at 
least one authentication mechanism is not permit- 
ted to access the resource, then access to the at 
least one resource Is not allowed to proceed. 

30 

9. The method as recited in Claim 6, wherein if the ac- 
cess control entry does not operatively specify that 
the at least one authentication mechanism is per- 
mitted to access the resource, then access to the 
35 at least one resource is not allowed to proceed. 



15 



Claims 

1 . A method for use In a computer capable of support- 
ing multiple authentication mechanisms, the meth- 
od comprising: 

generating at least one indicator associated 
with and Identifying at least one authentication 
mechanism; and 

controlling access to at least one resource 
based on the indicator. 

2. The method as recited in Claim 1 , wherein gener- 
ating the indicator further includes receiving inputs, 
providing the inputs to the authentication mecha- 
nism, and causing the authentication mechanism to 
generate at least one security identifier (SID) that 
identifies the authentication mechanism. 

3. The method as recited in Claim 1 , wherein gener- 
ating the indicator further includes identifying within 
the indicator at least one characteristic associated 



10. The method as recited in Claim 1, wherein the indi- 
cator includes a security token. 

40 1 1 . A computer-readable medium for use in a device 

capable of supporting multiple authentication 
mechanisms, the computer-readable medium hav- 
ing computer-executable instructions for perform- 
ing acts comprising: 

45 

producing at least one indicator that uniquely 
identifies at least one authentication mecha- 
nism supported by the device; and 
causing the device to selectively control access 
50 to at least one resource operatively coupled to 

the device based at least in part on the indica- 
tor. 

1 2. The computer-readable medium as recited in Claim 
55 11 , wherein producing the indicator further includes 

receiving inputs, providing the inputs to the authen- 
tication mechanism, and causing the authentication 
mechanism to generate at least one security iden- 
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tifier (SID) that identifies the authentication mecha- 
nism, in response thereto. 

1 3. The computer-readable medium as recited in Claim 

1 1 , wherein producing the indicator further includes 5 
identifying within the indicator at least one charac- 
teristic of the authentication mechanism. 

1 4. The computer-readable medium as recited in Claim 

1 3, wherein the at least one characteristic of the au- io 
thentication mechanism Includes a strength charac- 
teristic of the authentication mechanism. 

1 5. The computer-readable medium as recited in Claim 

14, wherein the strength characteristic Identifies a is 
length of an encryption key employed by the au- 
thentication mechanism. 

1 6. The computer-readable medium as recited in Claim 

1 1 , wherein causing the device to selectively control 20 
access to the at least one resource based on the 
indicator further includes causing the device to 
compare the indicator to control data . 

1 7. The computer-readable medium as recited in Claim 25 
16, wherein If the control data specifies that the au- 
thentication mechanism is permitted to access the 
resource, to which subsequent access to the re- 
source is allowed. 

30 

18. The computer-readable medium as recited In Claim 
16, wherein if the control data operatlvely specifies 
that the authentication mechanism is not permitted 
to access the resource, to which subsequent ac- 
cess to the resource Is prohibited, 35 

19. The computer-readable medium as recited in Claim 
16, wherein if the control data does not operatlvely 
specify that the authentication mechanism is per- 
mitted to access the resource, to which subsequent 40 
access to the resource is prohibited. 

20. The computer-readable medium as recited in Claim 
10, wherein the indicator includes a security token. 

45 

21 . An apparatus comprising: 

at least one authentication mechanism config- 
ured to generate at least one indicator that 
identifies the authentication mechanism; so 
an access control list; 

at least one access controlled resource; and 
logic operatlvely configured to compare the in- 
dicator with the access control list and selec- 
tively control access to the resource based on ss 
the Indicator . 

22. The apparatus as recited in Claim 21 , wherein the 



authentication mechanism is further configured to 
receive user inputs and generate at least one secu- 
rity identifier (SID) that identifies the authentication 
mechanism based on the user inputs. 

23. The apparatus as recited in Claim 21 , wherein the 
indicator further includes at least one identifying 
characteristic associated with the authentication 
mechanism. 

24. The apparatus as recited in Claim 23, wherein the 
at least one identifying characteristic associated 
with the authentication mechanism indicates a 
measure of strength of the authentication mecha- 
nism 

25. The apparatus as recited in Claim 24, wherein the 
measure of strength of the authentication mecha- 
nism identifies a length of an encryption key em- 
ployed by the authentication mechanism. 

26. The apparatus as recited in Claim 23, wherein the 
indicator includes a security token. 
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(S) A smart card adapted for a plurality of service providers and for remote installation of same. 

@ A smartcard that allows different Service Pro- 
viders to coexist on the smartcard with none of 
the Service Providers, nor the owner of the 
smartcard, having access to the files created 
for, or by, each of the resident Service Provid- 
ers. The operating system of the smartcard 
includes a root directory that owned by the 
smartcard's issuer/owner, and each Service 
Provider is a "user" that is installed by the 
issuer/owner. Each such user Is provided with a 
subdirectory of the root directory, and within 
the subdirectory the user creates files and sub- 
directories with files, as the user deems neces- 
sary. The operating system prevents all users of 
the smartcard. Including the smartcard's Is- 
suer/owner and the smartcard's holder, from 
accessing any files that are owned by any other 
user, when that user chooses to prevent such 
access. This power to exclude is effected 
through a password file that is owned by the 
. user and which cannot be altered by any other 
user. Including the smartcard's issuer/owner. 
Optionally, the smartcard's issuer/owner Is 
given the power to erase all files of a given user. 
Connection is effected with a protocol which 
authenticates all parties to the connection. 
Thus, in a connection between the smartcard 
and a user, the smartcard determines whether 
the user should be granted access, and the user 
detemiines whether the smartcard is a valid 
smartcard. Authentication of the possessor of 
the smartcard may also be effected. 

Q. 
UJ 
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Background of the Invention 

This invention relates to smartcards. 

Advances in microelectronics have made it pos- 
sible to put a vast amount of computing power in a 
small space. In fact, it is possible to effectively put an 
entire computer inside a credit card, creating thereby 
a "smartcard". Because of the tremendous process- 
ing and memory capabilities of the smartcard, it is ex- 
pected that smartcards will supplant conventional 
credit cards which, typically, serve to confirm the right 
of the card's holder to debit a given account Smart- 
cards will provide a higher level of assurance that the 
smartcard possessor is the rightful Holder. This will 
solve a major problem of conventional credit cards. 
Moreover, smartcards will be more than an "authorlz- 
er" to debit (or credit) an account. For example, they 
will "carry" pre-approved credit. 

To allow smartcards to fulfill their promise, Ser- 
vice Providers must feel secure that the computer 
within the smartcard cannot be employed for improp- 
er uses. A number of approaches have already been 
used for meeting this need. First, smartcards are pro- 
vided with a power port and a single information pass- 
through port Second, the computer embedded in the 
smartcard operates under control of an operating sys- 
tem which insures that instructions sent to the com- 
puter do not carry out operations that are detrimental 
to the card's purpose and security guidelines; i.e., 
only instructions that read and alter permitted data 
areas are allowed. Third, the issuers of today's smart- 
cards Insist on populating the card on the provider's 
premises and not through remote communication. 

The memory in smartcards is large enough to 
hold the programs and data of a number of service 
providers. That is, there is sufficient memory to allow, 
forexample, VISA, AMERICAN EXPRESS, and MAS- 
TERCARD to coexist on a single smartcard. Alas, 
smartcards have yet to be developed that, in a conv 
mercial sense, have succeeded in carrying the ser- 
vices of more than one Service Provider. It is believed 
that the reasons for this state of affairs is a number 
of security problems have not been solved. One prob- 
lem, for example, arises in connection with who is the 
card's owner, and what powers does the owner have 
over all the files in the smartcard 's memory. Stated in 
commercial temns, the question is to what extent does 
the owner of a smartcard (who may also be a Service 
Provider) have powers over the smartcard that are in- 
consistent with the security that other Service Provid- 
ers seek. This is a trust issue. 

A second issue relates to remote provisioning. 
Particularly, it is undesirable to require the smartcard 
holder to have a service installed only by brining the 
card to the provider. It is also undesirable to require 
surrender of the smartcard when one of the services 
on the smartcard is to be canceled. Rather, it is desir- 
able and perhaps even essential for commercial suc- 



cess, to allow remote provisioning. 

When the remote provisioning issue is solved, a 
third issue relates to the need to reuse space in the 
holder's smartcard as old services are canceled and 
5 new services are installed. 

A fourth issue relates to the commercial conflict 
between competitive services, and the desire by 
some providers to restrict access by their customers 
to competing services. 

10 

Summary of the Invention 

The issues described above are resolved with an 
operating system that allows different Service Pro- 
15 viders to coexist on a smartcard with none of the Ser- 
vice Providers, nor the owner of the smartcard, hav- 
ing access to the files created for, or by, each of the 
resident Service Providers unless authorized in ad- 
vance. 

20 The operating system of the smartcard, some- 
what akin to the UNIX® (registered trademark of 
UNIX System Laboratories) operating system, in- 
cludes a root directory that is owned by the smart- 
card's issuer/owner, and each Service Provider is a 

25 "user" that is installed by the issuer/owner. Each such 
user Is provided with a subdirectory of the root direc- 
tory and within the subdirectory the user creates files 
and subdirectories with files, as the user deems nec- 
essary. 

30 The operating system prevents ail users of the 
smartcard, including the smartcard's issuer/owner 
and the smartcard's holder, from accessing any files 
that are owned by any other user, when that user 
chooses to prevent such access. This power to ex- 

35 dude is effected through a password file that Is 
owned by the user and which cannot be altered by any 
other user, including the smartcard's issuer/owner. 
Optionally, the smartcard's issuer/owner is given the 
power to erase all files of a given user. 

40 The operating system also includes means for 
digital signature-supplemented communication as 
well as for completely encrypted communication. This 
capability imparts confidence in remote communica- 
tk)ns, which permits remote provisioning, effective 

45 maintenance of a database that keeps track of all ser- 
vices contained in each smartcards, and re-provision- 
ing of a smartcard in case of loss or general failure of 
the smartcard. 

50 Brief Description of the Drawing 

FIG. 1 depicts a tree structure of the UNIX oper- 
ating system; 

FIG. 2 presents the tree structure of a smartcard 
55 operating system; 

FIG. 3 shows a log-in protocol between a smart- 
card and its issuer/owner; 
FIG. 4 illustrates a protocol involving a smart- 
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card, the issuer /owner and a Service Provider; 
FIG. 5 presents a protocol fora smartcard obtain- 
ing services from a Service Provider; 
FIG. 6 presents a protocol involving a smartcard, 
a Visitor user and a Service Provider; and 
FIG. 7 presents a protocol between a smartcard 
and a Visitor user, without connection to a Ser- 
vice Provider; 

FIG. 8 depicts an arrangement for remote provi- 
sioning of smartcards using the telecommunica- 
tion network; and 

FIG. 9 presents a flowchart of an operating sys- 
tem command for drawing upon a value stored in 
a service provider's file. 

Detailed Description 

A number of smartcard operating systems are al- 
ready known. One example is U.S. Patent 4,81 6,653, 
issued to Anderl et al on March 28, 1989. The oper- 
ating system described below has many similarities to 
that operating system and to the well known UNIX op- 
erating system. A brief description of some well known 
aspects of the UNIX operating system will help in un- 
derstanding the smartcard operating system dis- 
closed herein. 

The UNIX Operating System 

The UNIX operating system comprises a collec- 
tion of files. Some are files that primarily contain in- 
formation about related files, and they are called di- 
rectory files or directories. Others are files that con- 
tain user data, and they are "normal" files. Also in the 
UNIX operating system, a user can be the "owner" of 
the file, can belong to a specified "group" recognized 
by the file, or can belong to "other". Each file contains 
a data portion that specifies the file characteristics, 
such as ownership, information access capabilities 
relative to the three types of users, etc. The owner of 
the file can change all file characteristics. 

Architecturally, the first and primary file is a root 
directory file. The user who is the owner of this direc- 
tory is, in effect, the owner of the entire operating sys- 
tem. This user can create other files which are point- 
ed-to by the root. file. These files, which can be other 
"directory" files as well as "normal" files, are consid- 
ered to be "below" the root directory, in a tree-like 
structure. 

In many UNIX operating systems, one of the di- 
rectories below the root is named "etc.", and It has a 
file below it that is designated "passwd". The full ad- 
dress, or path name, of that file Is "/etc/passwd" (the 
file "/" at the beginning of the path name designates 
the root address). The "etc." and the "passwd" files 
are owned by the system administrator, typically 
called "Root", who is the also the owner of the root dl- 
rectory. The "passwd" file contains an encrypted rep- 



resentation of Root's password, and Roofs access to 
the operating system is allowed only after Root logs 
in by providing the password. The presented pass- 
word is encrypted and compared to the encrypted 
s password stored in the "passwd" file. When the com- 
parison is favorable, the user is accepted and granted 
permission to access other files; i.e., the user is "log- 
ged in". 

Multi-user capability is provided by allowing Root 

10 to create a subdirectory below the root directory and 
to assign ownership of that subdirectory to another 
user. Root can then install a password for that user in 
the "passwd" file and allow the user to enter the sys- 
tem at that subdirectory file when that user presents 

f5 his/her password. The user has the ability to modify 
his/her own password, but only through a command 
provided by the operating system. That password re- 
sides in the system only in encrypted form and only 
in the "passwd" file. This architecture is depicted in 

20 FIG. 1. 

The log-in process can be summarized as fol- 
lows. A computer operating under the UNIX operating 
system begins by executing a loop that scans the 
computer's input port. When connection by a user is 

25 detected, control is transferred from the loop to a pro- 
gram that begins interactions with the user. The pro- 
gram sends a "login:" message to the user and waits 
for the user's response. The user identifies hin> 
self/herself, for example, by returning the string "htb" 

30 and that identifies the user to the operating system. 
The program then continues with the challenge mes- 
sage "Password:" and the user must supply a pass- 
word string. The program encrypts the password 
string and compares it to the encrypted password that 

35 is found in the "/etc/passwd" file for the identified 
user. When the match is positive it is determined that 
the user is bona fide, and control passes to a file 
owned by Root (typically named ".profile"). That file 
sets various parameters for the user and passes con- 

40 troi to another file that is owned by the user (typtealty 
also named ".profile", but this file is located In the di- 
rectory owned by that user). Whatever instructions 
are found in the user's ".profile" file are executed and 
the computer is placed in a loop, awaiting further In- 

45 structions from the user. 

Root Is the owner of all files that comprise the op- 
erating system, as well as of the "passwd" file. There- 
fore, Root can modify any and all files and is, there- 
fore, a "super user". It is Important to note that even 

50 files that are not owned by Root are nevertheless 
subject to Roofs commands. Reason: Root has the 
power to change the "passwd"f lie as well as the files 
the control Roofs capabilities generally That capabil- 
ity gives Root the power to change the password itself 

55 and, therefore, Root can always make itself the owner 
of a file. Hence, it makes sense to let Root have all 
owner powers In the first instance. In short, Root has 
absolute control and total knowledge over all files in 
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the system. 

Aside from being able to log in (by providing the 
correct password), users are granted the ability to 
read files, write into files, and execute files - i.e., pass 
program control to files. (Without the power to pass 5 
program control to a specified file nothing can be 
done, for executing a program Is noting more than 
passing control to a file.) Since Root has access to all 
files in the system, it follows that Root can read, write, 
and execute all files. to 

All systeni-provided instructions in the UNIX op- 
erating system are merely files that can be executed, 
and those files can be located in any directory - as 
long as the system knows where those files are 
found. As stated earlier. Root owns all those director- is 
ies and those files. Since Root controls the read and 
execute permissions of all those directories and files, 
it follows that Root can restrict anyone (including it- 
self, if that were desired) from executing any file, sinv 
ply by limiting the permissions of that file. That gives 20 
Root the power to create customized sets of files 
whose execution is blocked to particular groups of 
users. In other words, Root can create various re- 
stricted operating systems , or "restricted shells", that 
encompass less than all of the commands available 25 
on the system. 

The Smartcard Operating System 

The absolute power that Root has in the UNIX op- 30 
erating system makes it unsuitable for smartcards. 
While it is patently clear that providers such as VISA, 
MASTERCARD, and AMERICAN EXPRESS will not 
allow each other to be the Root, it is also quite likely 
that, absent demonstrably sufficient security means, 35 
they would not want anyone else to be the Root either. 
That is part of the problem that has been blocking the 
smartcard from enjoying the commercial success it 
deserves. 

FIG. 2 illustrates a structure that responds to this 40 
sensitivity of Service Providers. According to the 
structure of FIG. 2, Root owns the root directory and 
any number of files (directory files or normal files) 
that it wishes to create. For example, FIG. 2 includes 
a root directory file 1 0 and below it there are ".profile" 45 
file 11. "passwd" file 12, Hog" file 17. "filex" file 13, 
"flley"file 14, and "ID" file 18. A number of subdirec- 
tories are also found below root, with each being used 
as the "HOME" directory of a user (Service Provider). 
For example, FIG. 2 includes a directory file 15, so 
named "htb" (the smartcard's Holder), a directory file 
20 named "bankA", and a directory file 25 named "air- 
lineA". Each one of the directories includes a 
"passwd" file (16, 21, and 26, respectively) below the 
associated user's HOME directory, as welt as a "pro- ss 
file" file. This placing of the password files has some 
advantages by it is not a requirement importantly, 
ownership of each such password files is assigned to 



the user associated with that file and the directory 
above it It may also be advantageous to grant own- 
ership of directories 15, 20 and 25 to the respecth/e 
users. 

FIG. 2 includes one additional important directo- 
ry (and a user). That is the "Visitor" directory 30, 
which is the entry point for non-Service Providers 
who wish to interact with the smartcard. 

The FIG. 2 file architecture is coupled to an op- 
erating system that differs from that of the UNIX op- 
erating system primarily in that the operating system 
of the FIG. 2 structure does not allow Root the ability 
to modify files that it does not own. To insure that this 
capability is not circumvented by Root, the operating 
system does not allow Root to modify some of the 
files that define the operating system (in a sense, 
Root does not own those files). One means for ach- 
ieving the latter result is to encase those non-Root- 
owned operating system files in a read-only memory 
(ROM). At the very least, the ROM contains the com- 
mands/modules/f lies that effect writing to a file. More 
specifically, the writing to a file is restricted to what- 
ever the owner of the file specifies (the owner of a file 
is, initially, the user that creates the file), and Root is 
treated as merely another user. Commands that ef- 
fect writing to a file are operating system commands 
that for example, move files, copy files, save files, 
change file attributes (e.g., ownership), and rename 
files. Other items that may be installed in the ROM, 
or more typically in a "write once" memory (because 
they are unique to each smartcard), are the Root 
password and the smartcard's ID information (i.e., 
files 12 and 18) The ID information may be simply an 
arbitrary string, or it may include the Holder's name. 
Including the Holder's name Is probably prefenred by 
merchants who will get the ID information. Actually, 
both the Root password and the smartcard 's ID can 
be encased in the file that establishes the Root direc- 
tory (i.e., in block 1 0). In FIG. 2 these are independent 
files, however, to more clearly illustrate the concepts. 

One file-writing power that is granted to Root in 
some embodiments is the power to delete any file In 
its entirely (and in the process, effectively deleting 
any file that the deleted file points to). This includes 
directory files and normal files and it applies to files 
that Root owns and to files that Root does not own. 
Such a capability may be given in embodiments 
where memory space is to be reused when a given 
Service Provider is no longer providing services to 
the smartcard's Holder. 

Another difference between the operating sys- 
tem of FIG. 2 and that of a standard UNIX operating 
system is that the former includes an encryption key 
pair that is installed in a file owned by Root (e.g., in 
"filex" 13), and that key pair is unique to each smart- 
card. The pair includes a private key, f, that is kept se- 
cret by the smartcard, and a public key. g, that the 
smartcard does not care to keep secret Of course, 
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both keys are initially known to the snnartcard's own- 
er/issuer, who is also the Root user (i.e., super user) 
of the smartcard. but Root need not keep the private 
key (and probably would choose to destroy that 
knowledge). This pair of keys can also be "burned" 
into an appropriate memory, such as the memory 
containing Roofs password, or included in the file 
that defines the root directory. More about public key 
encryption Is found below. 

The fact that the password of a user's directory 
is stored in a file that is owned by the user is a key 
difference between the UNIX operating system and 
the operating system shown in FIG. 2. The fact that 
these passwords can't be read by anyone other than 
the files' owners permits storing the passwords in an 
unencrypted form. Combined with the restriction on 
writing, this organization prevents Root from becom- 
ing the owner of any file (normal file or directory file), 
and thus prevents Root from circumventing the per- 
missions set by the file's owner. This key difference 
allows one user's files to be completely opaque to 
Root as well as to other users. Thus, the FIG. 2 ar- 
rangement overcomes the "trust issue" between the 
providers of services and the smartcard's issuer/own- 
er. 

Transactional Security 

The next issue that must be addressed is trans- 
actional security of the smartcard. This concept en- 
compasses the measures employed by the smart- 
card's operating system and by the agreed upon conv 
munication protocols to ensure that unauthorized 
transactions do not occur which would adversely af- 
fect the Holder or any of the Service Providers. This 
includes activities by Root, the Holder, any of the Ser- 
vice Providers, any Visitor user, or an interloper. (An 
interloper is a party that interjects itself into a commu- 
nication session between a smartcard and another 
party and substitutes its messages for the true mes- 
sages.) 

One way to thwart Interlopers is to construct 
messages that include a date and time stamp, with at 
least that portion of the message being encrypted. Al- 
ternatively, the entire message can be encrypted. 
Also, wherever necessary, the communication proto- 
col can require a confirmation sequence (which dif- 
fers from session to session) to be exchanged be- 
tween the parties. It is also a good general approach 
to minimize the flow of sensitive Information in the 
clear (i.e., without encryption). These techniques are 
employed in the log-in and communication protocols 
described below. 

Encryption 

The field of encryption is not new. What follows 
is merely a summary of two encryptbn techniques 



that may be employed in connection with the smart- 
card disclosed herein. 

As is welt known, the "shared secref approach to 
encryption calls for the two communicating parties to 

5 share a secret function, f. The party wishing to trans- 
mit a message, m, encrypts the message with the se- 
cret function to form an encrypted message f(m). The 
encrypted message is transmitted and the receiving 
party decrypts the received signal by forming the 

10 function f(f(m)). The function f is such that discover- 
ing the message m from f(m) is computationally very 
difficult, but applying the function twice recovers the 
original message; I.e., f(f(m))=m. 

The "shared secret" approach to encryption Is 

15 very good, but its weak link lies In the need to com- 
municate, i.e., or share, the secret functbn. If an 
eavesdropper obtains the shared secret during that 
singular communication session when the function is 
transmitted, then it is no longer secret. 

20 In public key encryption, each party maintains 
one member of a pair of keys, f and g. More particu- 
larly, one party keeps one key (0 secret, but makes 
the other key (g) known to all. Thus, the key g is "pub- 
lic" and the key f is "private". The pair, f and g, is such 

25 that 

1 . g(f(m))=m. 

2. even when g is known the function f cannot be 
determined, and 

3. it is computationally infeasible to determine the 
30 message m from f(m). 

Whereas the public key approach solves the key 
distribution/administration problem described above, 
it does have a disadvantage in that public key encryp- 
tion and decryption is slower (requires more compu- 

35 tation time) than the "shared secret" approach. 

As it relates to smartcards, speed of communica- 
tion has different levels of importance, based on the 
kind of party that is communicating with the smart- 
card. With respect to the smartcard's issuer/owner 

40 and the service Providers, low speed is not a major 
disadvantage because it is expected that such com- 
munication will be rare and, therefore, processing 
time is not "of the essence". In communication with 
others, however, (I.e., merchants that log in as the 

45 Visitor user), speed is important. 

The speed issue is resolved, where necessary, 
by combining the "shared secret" approach with the 
public key approach. That is. when communication is 
initiated, the public key approach is used to oommu- 

50 nicate a temporary "shared secret" between the 
smartcard and the merchant. Specifically, the party 
having the public key suggests a "shared secret" and 
communicates it to the party having the private key. 
Thereafter, the faster, "shared secref, approach is 

55 used to encrypt the entire messages. 

Alternatively, a certification approach may be 
used (using the shared secret). In a certification ap- 
proach, the message is sent in the dear, and is ap- 
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pended. or "signed", with a "digital signature". A "dig- 
ital signature" is a hashing of the nfiessage (e.g., add- 
ing the ASCII codes of the characters in the message, 
in a selected modulus) that Is encoded. Of course, in 
applications where it is assured that an interloper can- 
not substitute the true data with false data the infor- 
mation can be sent in the clear (prot>ably, following a 
verification process using the public key). 

Use of the public key approach solves most of the 
key-administrations concerns. It still leaves the ques- 
tion of the initial knowledge of the public key by the 
party wishing to communicate with the smartcard, but 
that is a non-problem since the smartcard itself can 
provide that information. 

Log-in by Root and Installation of a Service 

Provider/User 

Because encryption ensures secure communica- 
tion, the smartcard's issuer/owner can have confi- 
dence in remote installation of services. Of course, 
the issuer/owner (i.e., Root) must first log In into the 
smartcard. A protocol for the log- in is presented in 
FIG. 3, and a protocol for service installation process 
is presented in FIG. 4. The physical remote, connec- 
tion that Is possible with the smartcard disclosed 
herein is shown In FIG. 8. 

As depicted in FIG. 3, the process begins with the 
smartcard's possessor (P) being authenticated as the 
bona fide Holder (H) of the smartcard (S). As shown 
in FIG. 3, the process begins with a prompt from the 
smartcard, and anentry of the possessor's PIN (Per- 
sonal Identtf ical Number) into the smartcard. The use 
of the smartcard's processing power to authenticate 
the possessor has an advantage in that it requires no 
communicatk>n of the PIN string to any equipment 
that might capture the PIN. Even in applications 
where P and S are at a merchant's premises, it is pos- 
sible for the merchant to possess a stand-alone piece 
of equipment that Interfaces with the smartcard in a 
secure manner. This equipment may be battery oper- 
ated, with a keyboard and a display and certified to 
include no other ports, no processor, and no writable 
memory. In operatbn, P would insert S into this 
stand-alone equipment, input the PIN via the key- 
board, and the smartcard would determine whether 
the PIN is correct. It would then output an "OK" mes- 
sage through the display, if appropriate. 

When such stand-alone equipment is unavailable 
(or when the communication is remote as, for exam- 
ple, when a "dumb" card reader is used at the posses- 
sor's home), the submitted PIN is processed in the 
smartcard and the "OK" message from the smartcard 
(to the merchant's equipment) is "time stamped" and 
encrypted. This suggests that the P's confirmation as 
H must be postponed until after the appropriate en- 
cryption keys are established and date and time infor- 
mation Is Imparted to S (this is not the approach 



shown In FIG. 3). 

Returning to FIG. 3 generally, after the bona fide 
of H is established. S verifies that the user logging is 
a valid user and the user confirms that S is a valid 
5 smartcard. More specifically, the protocol of FIG. 3, 
in its entirety, proceeds as follows: 

a. S prompts for an input and P provides a PIN 
string. (Within the smartcard the PIN resides in a 
Root-owned file that is open for the Holder to 

10 modify, for example, file 14 in FIG. 2). S conv 

pares the provided PIN string to the stored PIN 
string, and, if the comparison is positive, then P 
Is conf inmed as H. 

b. Once H is confirmed, attention can turn to the 
15 communication between S and O. S identified it- 
self by providing to 0 its ID number and a pass- 
word challenge in the form of a random string, 
RND1. 

c. O encrypts RND1 with O's password to form 
20 string Ki(RND1)and returns it to S. This form of 

password response obviously changes from ses- 
sion to session and ensures that the true pass- 
word of O is not snared by an interloper. There 
does remain the question of where O keeps the 

25 passwords of all the smartcards that it owns, and 
how secure such a database is. However, there 
Is actually no need for O to keep a database of 
passwords. All that O needs is a single seed 
string which, when processed with the data sup- 

30 plied by S, yields the smartcard's password. That 
data is the ID information. 

d. Since the string submitted by the smartcard 
will always be either the same or unknown to O 
beforehand, an additional authentication step 

35 may be desired to ensure that the initial string (ID, 
RND1) is not a replay of a recording. This is ach- 
ieved by O sending a challenge message, RND2, 
to S comprising, for example, its ID and a random 
string. 

40 e. Based on the ID contained in the RND2 string, 
S determines that O is the user, obtains the nec- 
essary keey (e.g., O's password), and decrypts 
Ki(RND1). When the decryption results in RND1, 
S determines the O is bona fide. 

45 f. Thereafter, S encrypts string RND2 with S's 
Root password and forwards the resultant string, 
Ki(RND2), to O. 

g. O decrypts the Ki(RND2) response, and if the 

resulting string is RND2 then O is satisfied that 
50 S is valid. This ends the log-in process, with O 

presenting a prompt to S and standing ready to 

accept requests for service. 

It may be noted that the "log-in" process descri- 
bed above appears to be different from the familiar 
55 log-in process where the computer into which access 
is directed controls. The computer asks for an initial 
identification of the user, and then asks for a pass- 
word. Based on that Initial Identification, the comput- 
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er knows what password to expect. Here, the smart- 
card appears to be in control, in the sense that it ini- 
tiates the communication (with O); but instead of ask- 
ing for an Initial identification ~ to get information ~, 
it provides information — the ID and RND1. That rais- 
es the question of whether the response from O Is the 
Initial Identification, or the password; and If it Is the 
password, then how does S know whether the pass- 
word is correct. The answer is that the response from 
O serves three purposes: it identifies itself in the 
sense of the initial Identification (by the ID contained 
In RND1), It authenticates Itself by using the correct 
key to encrypt RND1 , and It challenges S by RND2 to 
be returned in an encrypted mode. 

Once O is logged In, H can communicate a re- 
quest for installation of a service offered by a Service 
Provider (SP). The communication regarding the par- 
ticular service requested to be Installed by O may in- 
volve interaction with a human, but it can also be au- 
tomated. For example, H can communicate to S the 
service that is desired, and S communicates with O. 
FIG. 4 presents a protocol for Installation of service. 

a. H forwards a service request to S 

b. S encrypts the request and forwards It to O. 
The electronic communication between O and S 
can be encrypted with the private key member of 
the public key within S, with S sending Its public 
key to O. Alternatively, the communication can be 
encrypted with a "shared secret" of the smart- 
canj. The Root password may be selected for the 
latter, or a temporary "shared secret" can be of- 
fered by O to S (using public key encryption, as 
described above). In FIG. 4, the Root password 
is used for encryption, creating the request string 
Ki(REQ). 

b. Knowing the desired service, O contacts SP to 
verify that SP consents to offer service to H 

c. If provision of service Is agreeable to SP, O se- 
lects a temporary password, Informs SP of that 
password (probably through encrypted communl- 
catk>n), and proceeds to create In S a directory 
and a password file for SP. 

d. When the password file Is set up for the SP 
user, the temporary password is sent to S (conv 
munlcated In encrypted manner, as described 
above) and ownership of the directory and the 
password file is transferred to SP (this password 
can serve as the "shared secret" key in future 
communication sessions with SP). Also, the rest 
of the application software that SP requires can 
be installed at this time, with O transmitting those 
files in encrypted mode. Alternatively, it may be 
arranged that no application software Is installed 
byO. 

e. At this point H is informed to contact SP for a 
final set-up. 

f. H sets up a communication path between S and 
SP, employing a log-in sequence as shown In 



FIG. 3 but using the temporary SP password as 
the encryption key. 

g. Once the log-in to SP Is established, S sends 
out a request for service, and SP responds by in- 
5 stalling a new password, as well as data and 

whatever files are necessary which were not in- 
stalled by O, and data. This completes the ser- 
vice Installatbn process. 

10 Provision of Service by a Service Provider 

As Indicated above, a Service Provider Is simply 
a user having an assigned directory in the smartcard. 
The Service Provider logs in when the Possessor es- 
15 tablishes communication between the smartcard and 
the Service Provider. As before, there are three ele- 
ments to the log In protocol: 

(1) SP wishes to establish that P Is H, 

(2) S wishes to determine that the logged In user 
20 is the true SP, and 

(3) SP wishes to determine that it is communicat- 
ing with a valid S. 

These three elements are carried out in the pro- 
tocol disclosed in connection with FIG. 3. Only after 

25 a successful log-In, can a service request be ad- 
vanced. A service request may comprise, for exanv 
pie, H requesting SP (e.g., a bank) to Install "money" 
into S, filling the "electronic purse" of S. The filling of 
the electronic purse may simply be Installing a value 

30 In a file owned by SP. This is shown In the flowchart 
of FIG. 5. 

Interactfon with Merchants 

35 It is expected that, by a wide margin, the smart- 
card holder will mostly wish to have the smartcard in- 
teract with merchants who are Visitor (V) users. The 
arrangement disclosed above permits such interac- 
tion in two ways: direct interaction between the 

40 smartcard and a merchant, and a three way Interac- 
tion Involving the smartcard, merchant and the Ser- 
vice Provider. The protocol for the latter approach, 
shown in FIG. 6, may be as follows: 

a. P sets up communication between S and V (by 
45 handing S to V or by remotely connecting S to V). 

b. S prompts for an input and P provides the PIN 
string. When that checks out, S determines the P 
Is H and proceeds with the standard "log-In" se- 
quence, sending its ID information and RND1. 

50 c. V sets up a communication path with SP, iden- 
tifies itself to SP, and relays the ID information 
and RND1. 

d. Given the ID information, SP determines Its 
password (perhaps also using a seed string com- 

56 bined with processing) and encrypts RND1 with 

that password. The resulting string, K2(RND1), is 
sent to S, together with a random string RND2. 

e. S determines whether SP used the correct 
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password in forming K2(RND1) and, if the conclu- 
sion is positive, encrypts RND2 and forward the 
result. K2(RND2). to SP. 

f. When SP confirms that S used the correct 
password to encrypt RND2, it sends a prompt to 5 
V to inform the merchant that the it can proceed 

to request usage of S. 

g. V requests action from SP (such as deleting a 

value from IH's account with SP, or such as mod- 
ifying a value in a file residing in S and owned by io 
SR 

h. SP fills that request and, If necessary, sends 
an appropriate command to S, encrypted with the 
SP password. 

When it is desired to have the smartcard interact is 
directly with the merchant (or a merchant in concert 
with the merchant's bank, or some other entity that 
provides a service to the merchant and stands "in the 
shoes" of the merchant) a mechanism needs to be es- 
tablished for allowing parties who do not have a pre- 20 
established relationship with the smartcard to log in 
into the smartcard. The "Visitor" user directory serves 
that need, and that user has no password. That 
means that the Visitor user is a very insecure user, so 
its access must be strictly controlled. 25 

One question that needs to be answered, for ex- 
ample, is whether such a Visitor user will have access 
to application files (programs) of only the Service 
Provider specified by the merchant, or to application 
files of all Service Providers. 30 

If access is to be granted to application files of all 
Service Providers, then the simplest arrangement is 
for Root to establish a Visitor user directory with no 
password and with a restricted shell which allows the 
Visitor user to execute only a limited set of operating 35 
system commands; i.e., with the variable PATH Is set 
up to contain one directory owned by Root (which in- 
cludes only few operating system commands) and the 
SP directories (or chosen subdirectories of the Ser- 
vice Providers/users) which contain the executables 40 
to which the SPs wish to grant execution access to 
Visitor users. 

If access is to be granted to application files of 
only a specified SP then, of course, that SP must be 
specified and means must be provided to include only 45 
the executables of the specified SP. Again, that is 
easily accomplished with a restricted shell, where the 
PATH variable includes the directory (or chosen sub- 
directory) of the specified SP. The protocol, depicted 
In FIG. 7, may be as follows: so 

a. S prompts for an input and P provides the PIN 
string. When that checks out, S determines the P 
is H and proceeds with the standard "log-in" se- 
quence, sending its ID information and RND1. 

b. Since V does not have any passwords, it mere- ss 
ly returns the string RND1. 

c. By this response S recognizes that the user Is 
a Visitor user and sends out its public key, Kpu. 



(The public key could have been sent as part of 
the ID information.) At this point S can also send 
a "digital signature" that is derived from a mes- 
sage that contains the public key, the ID informa- 
tion and RND1. S can also send an encrypted 
string that constitutes a proposed "shared secret" 
(not shown in FIG. 7). The digital signal is en- 
crypted with the public key. 

d. V deciphers the "digital signature", using the 
provided public key. If the deciphered "digital sig- 
nature" matches the appropriate string then V 
sends out RND2. 

e. S encrypts RND2 with its private key and re- 
sponds with Kpr(RND2). 

f. V decrypts this message with Kpu and if V ob- 
tains RND2 then V is satisfied that it is commu- 
nicating with S. 

g. V sends time and date information to S, en- 
crypted with Kpu, and S returns a prompt. 

h. V transmits a request to S (identifying the ac- 
tion V seeks and the SP that is to be employed), 
also encrypted with Kpu, and S responds with an 
authorization to contact the specified SP. The au- 
thorization is encrypted with the private key, Kp^. 
Typically, the merchant wants to receh^e funds 

that belong to H, in exchange for goods or services 
provided by the merchant. As described above, it is 
quite possible for a Service Provider, such as a bank, 
to install an "electronic purse" that will hold a value. 
This value is In a file owned by the Service Provider. 

The merchant wants access to this file, and SP 
(in concert with the H) is willing to grant access to this 
file, but only in a very limited and strictly controlled 
way. Thus, SP creates a file with a prescribed name 
that Is expected by the operating system, populates 
this file with a value, and a specific operation system 
command (that is not owned by Root) accesses the 
file and deducts a sum from the value found in the 
file. 

A flowchart of such a command is illustrated in 
FIG. 9. the command starts at block 200 by perusing 
through a file (of a prescribed name) in the Visitor 
user directory. The file must contain four entries, 
separated, for example, by a newline character, and 
the operating system assumes that the four entries 
comprise a) date and time, b) merchant's ID, such as 
name address, and perhaps a code, c) the sum of 
money that is to be deducted, the d) the Service Pro- 
vider whose "electronic purse" is to be used. 

When that file does not exist or doesn't have the 
rquired number of entries, control passes to block 210 
which informs the merchant (Visitor user) of the defi- 
ciency. When the file does exist, the command reads 
the value in the "electronic purse" file of the Service 
Provider (SP) in block 220. This file is a file that has 
a prescribed name. Block 230 evaluates whether the 
sum that the merchant wishes to withdraw is greater 
than the value in the electronic purse. If It is, control 
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passes to block 240 which constructs a rejection 
message and forwards it to the merchant and to the 
log file within the smartcard. When sum is lower than 
the value, control passes to block 250 which checks 
the log file for various indicia of fraud. This may be a 
separate command that is called by the command be- 
ing executed. As depicted in FIG. 3, block 250 can re- 
sult in three types of outputs: one that suggests a po- 
tential fraud condition (e.g., this merchant has used 
the smartcard more than a prescribed number of 
times within a preselected time interval, the data and 
time given by the merchant is earlier than the latest 
time found in the log file, etc.); another that responds 
to a threshold file provided by the SP which directs 
the merchant to conference the SP to the transaction; 
and the third that Indicates a normal condition. 

The potential fraud condition is handled by infor- 
mation being stored in the Holder's log file (block 260) 
and control then passes to block 240. The ifnormation 
stored identifies the merchant, what was attempted to 
be withdrawn, the reason for the rejection, etc. This 
provides the Holder with the Infbnmation necessary to 
interact with the issuer/owner of the card and with 
government authorities, as necessary. If desired, the 
smartcard Is disabled when a fraud condition is sus- 
pected. 

When a threshold set by SP is exceeded (e.g., SP 
desires withdrawal authorization in excess of $1,000 
to be granted "in real time"), a message is construct- 
ed in block 270 and control passes to block 280. 

Block 280 is also arrived at directly from block 
250 when a normal condition is indicated. Block 280 
increments the sequence number found in the smart- 
card's log file and deducts the sume desired by the 
merchant from the amount in the value file. There- 
after, block 290 creates a string that comprises the 
new sequence number the data and time, the mer- 
chant's identification infonmation, the sum, and the 
SP. Block 300 creates a digital signature of the string 
and block 310 creates a message that comprises the 
message constructed in block 220, the string con- 
structed in block 300, and the digital signature. Final- 
ly, that message is sent to the merchant and to the 
smartcard's log file. 

The merchant's equipment will do one of two 
things. When a message to conference SP is found to 
be present, the merchant's equipment connects itself 
to SP and forwards the message created in block 31 0. 
The merchant can then get immediate credit for the 
sum (provided, of course, that based on the signature 
the message is concluded to be valid). When the mes- 
sage received by the merchant does not include a 
message constructed by block 220, then the mer- 
chant can simply store the authorization string, col- 
lect such authorization strings over a chosen time in- 
terval (for example, the entire work day), and then for- 
ward the authorization strings to the appropriate SPs. 

The authorization string is shown encrypted with 



the private key of S, but It can also be encrypted with 
the password of the specified SP. The authorization 
string must t>e robust enough ensure that the mer- 
chant does not merely duplicate it a number of times 

5 and send it to the SP. This can be accomplished in a 
number of ways, including having the date and time 
stamp, an Indication of the "before" and "after" values 
in the value file, having a sequence number supplied 
by S, etc. Since this authorization string is not deci- 

10 pherabie by V and hence unalterable, security Is 
maintained. 

Smartcard IssueiyOwner as a Service Center 

15 One aspect of the arrangement disclosed herein 
is that the smartcard's issuer/owner (O) has a general 
knowledge of, and control over, the service providers 
whose "applications" are present on the smartcard. 
First, O controls the establishment of a Service Pro- 

20 vider's directory. Second, O can delete any directory 
at the holder's request, or whenever O gains access 
to the smartcard (with, or without, the holder's con- 
sent). Third, O is the only party who knows the iden- 
tity of all the Service Providers who share the smart- 

25 card, and various particulars about those Service 
Providers. Fourth, through the operating system's de- 
sign, O can control the amount of memory that each 
Service Provider has access to, and thus can control 
the number of Service Providers that can "coexist" on 

30 a smartcard. Fifth, O can define a Service Provider's 
grouping for particular types of transaction. Sbdh, for 
the privilege of being on the smartcard O can charge 
each such Service Provider in proportion to the space 
occupied by the Service Provider. 

35 As can be appreciated from all of the above, a 
number of benefits accrue from this arrangement. 
One that hasn't been mentioned before is that O has 
the power to "fix" a defective card and reinstall all of 
the services on it (typical power of an owner). Con- 

40 versely, O has the power to delete all directories. This 
latter power is exercised when it is determined that a 
security breach has occurred. 

With regard to security, there are four forms of at- 
tack that need to be considered: one is when an in- 

45 terloper tries to become Root, another when the In- 
terloper tries to become a Service Provider, a third 
when a party (Root, a Service Provider, and interlop- 
er, a Visitor, or the Holder) tries to do more than is per- 
mitted, and a fourth when the possessor is not the 

50 bona fide Holder. 

With respect to the first form of attack, it is the 
Root password which is the first and primary sentry. 
It Is an effective sentry in that the operating system 
is set up to completely disable the smartcard when a 

55 log-in as Root is attempted but fails. For example, all 
directories can be erased. 

An attempt to log In as a Service Provider should 
be only slightly more forgh^lng. Thus, It can be ar- 
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ranged for a counter to keep track of failed attempts 
to log in as a Service Provider. Wlien the number of 
failed attempt exceeds a preselected value (for exam- 
ple, 4) the smartcard again disables itself. In such sit- 
uations it may be desired to direct the smartcard dis- 
ablement only to the directory of the Service Provider 
who was the object of the attack, or to all of the Ser- 
vrce Provider directories but not to the Root directory. 

As stated above, the most numerous contacts 
with the smartcard will be by Visitor users. While 
these contacts need to be flexible, they also need to 
be vigilant Whereas in the UNIX operating system an 
attempt to execute a command that is not found in the 
PATH results in a benign message, the smartcard 
needs to monitor these attempts to access impermis- 
sible commands. Again, a counter can be employed 
and when a preselected count is exceeded, commu- 
nication with the Visitor can be terminated, a message 
stored in the smartcard, and the card disabled to ev- 
eryone except the Holder. The message, which would 
be stored in the holder's directory, would comprise 
the particulars of the aborted transaction. Similar ac- 
tions would be taken if the Holder attempt to execute 
impermissible commands, but the diagnostic mes- 
sage would then be written to a Root-owned file. 

Another security measure might even involve val- 
id transactions by the Visitor. As described above, 
one of the files owned by Root is a log file, which 
maintains a record of all transactions carried out by 
the smartcard. This file can be checked to disallow a 
particular Visitor user, or all Visitor users, when par- 
ticular circumstances appear to be present, such as 
too many transactions by one visitor in a given time 
Interval, too many transactions in a given time inter- 
val, etc. 

A slightly different security problem manifests it- 
self when the parties making contact with the smart- 
card are OK, but it is the possessor of the card who 
is the problem. Here, itcan easily be assumed that the 
parties interacting the smartcard would like to coop- 
erate in the prevention of the smartcard's use; at that 
point, and henceforth. This can be accomplished in a 
number of ways. For example, when, during the log- 
in sequence it is determined that the ID provided by 
the possessor is wrong (because, for example, the 
smartcard is a stolen one), the merchant can execute 
a command that writes a message to a file belonging 
to Root and disables the card. In such an event, the 
only way to recover the card is to contact Root When 
Root reads the diagnostic message in Its file, a deter- 
mination can be made whether the Possessor is in 
fact the true Holder or not, and proper action can be 
taken. 

Alternatively, the merchant's equipment can au- 
tomatically connect the smartcard to the card's issu- 
er/owner. The owner first disables the smartcard and 
then proceeds to interact with the smartcard's pos- 
sessor to determine whether the possessor has au- 



thority to possess the smartcard. If the possessor 
does have that authority, the issuer/owner re-enables 
the smartcard. 

Given the above-disclosed structure and operat- 

5 ing system of the smartcard, it is dear the issuer/own- 
er who installs all services found on the smartcard 
has knowledge of those services. That is, although 
the issuer/owner does not have the power to delve 
into files owned by the various Service Providers 

10 (even though it is the Root owner of the smartcard) 
the issuer/owner nevertheless knows of the specific 
Service Provklers are resident on each of its smart- 
cards. This knowledge can be maintained in a data- 
base owned by the Issuer/owner (although each 

15 smartcard can also maintain that information about it- 
self). 

In the event a smartcard is lost or destroyed, a 
new smartcard can be issued to Holder with all of the 
Service Providers installed ab initio. The only items 

20 that cannot be recovered are the data files created by 
the various users In the old file and the Service Pro- 
viders' passwords. As with Initial Installattons, a set of 
temporary password files can be installed. The Ser- 
vice Providers can then be contacted by the is- 

25 sue/owner to inform them of the temporary pass- 
words, and the Holder then contact the Service Pro- 
viders to modify the passwords and to populate the 
necessary files in their respective directories. 

30 Audit Trail 

As indicated above, Root can maintain a log file 
and store therein a record of each transaction. This 
file can then be used to keep tract of various thresh- 

35 olds that the Holder, or the Service Provider's may 
wish to impose. 

Excessive uses of a smartcard can be an indica- 
tion of a fraudulent use. As indicated above, such 
uses can be detected through careful scrutiny of the 

40 log file and stopped. 

Another use of the log file relates to perfectly val- 
id uses. For example, a credit-providing Service Pro- 
vider may wish to be informed in "real time" whenever 
charges over a certain limit are incurred, while allow- 

45 ing "batch" transmissions from the merchants (per- 
haps at the end of the work day) for all smaller trans- 
actions. In connection with the electronic purse of a 
smartcard, the Holder may instruct the smartcard to 
automatically contact the Holder's bank when the 

50 money value in the smartcard is below a certain limit, 
and transfer some additional funds into the smart- 
card. 

Still another use of the audit trail relates to dis- 
pute resolution. If a merchant asserts that the smart- 
56 card was used to obtain some goods or services and 
the Holder disputes the assertion, the log file can be 
used to resolve the dispute. 

10 
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Cooperation Between Service Providers 

It is quite possible for service providers to form 
cooperative alliances. Such alliances can specify va- 
rious activities which are carried out in the snrtartcards 
whenever the smartcard Is accessed, or when the 
smartcard is accessed by a particular user. The nunv 
ber of such possibilities Is limitless, and the example 
below is merely illustrative. 

Assume, for example, that company Z employs 
traveling salespersons who, expectedly, need to pur- 
chase gasoline fairly regularly. Z Is likely to contract 
with O to issue a smartcard for each of Z's salesper- 
sons (Holders) and request O to install Z as a Service 
Provider and G as the gasoline provider. Sometime 
later, A may reach an agreement with bank B as a Pro- 
vider of credit for the salespersons. That service can 
be remotely installed into all of thesmartcards belong- 
ing to the salespersons by, for example, obtaining the 
cooperation of G. 

Specifically. Z can request G to install a request 
for communication with O whenever a smartcard in- 
teracts with G and found to have A as a user but not 
B as a user. All that G needs to do is send the appro- 
priate command when the right kind of smartcard is 
logged into G. 

The above disclosure speaks of "smartcards" but, 
actually, in connection with the inventk)n disclosed 
herein, what we think of is any personal information 
device that is Intended to primarily accompany a per- 
son wherever that person goes. Thus, the intent of the 
claims that follow is for the term "smartcard" to en- 
compass all apparatus that is designed for personal 
use and is intended, at least in some of its functions, 
to carry Information about a person. This clearly In- 
cludes, for example, cellular phones and personal 
communicators. They already have the electronic 
means necessary to enable implementing this inven- 
tion (e.g., processors), and the curent expectation is 
that people will carry these electronic apparatus on 
their persons, much like people carry conventional 
credit cards. 



Claims 

1. A multiple-application smartcard including a 
processor and memory in connection with which 
there is an issuer/owner, a holder and a service 
provider, comprising: 

an operating system that includes a tree- 
like file structure that begins with a file having 
characteristics that are controlled solely by said 
issuer/owner; 

a plurality of files, forming part of the tree- 
like structure and each having file characteristics 
that are controlled solely by said Issuer/owner, 
which files are executable files, In the sense that, 



when referenced, they operate on permissible 
data in said memory; 

a password file that is accessible only to 
said issuer/owner, which contains data and which 
5 is accessed by said issuer/owner prior to said is- 

suer/owner gaining access to said executable 
files; 

a password file that is accessible only to 
said holder, which contains data and which is ac- 
10 cessed by said holder prior to said holder gaining 
access to said executable flies; an 

a password file that is accessible only to 
said service provider, which contains data and 
which is accessed by said service provider prior 
15 to said service provider gaining access to said 
executable files. 

2. A smartcard adapted for communicating with a 
party and including a processor comprising: 

20 a memory arranged into a plurality of infor- 

mation storage and retrieval user entity logical 
zones, with at least two of said logical zones in- 
cluding sub-zones that encompass a memory 
segment that contains access control data, and 

25 control means, for allowing access by said 

party to a selected one of said user logical zones, 
including its associated sub-zone, only when said 
party deliver to said smartcard information relat- 
ed to the access control data contained in said 

30 selected one of said user logical zones. 

3. In connection with a smartcard issued by a first 
party, where the smartcard includes an operating 
system having a tree-like file structure that be- 

35 gins with a directory-file with attributes that are 
controlled solely by said party, a plurality of files, 
forming part of the tree-like structure and each 
having file attributes that are controlled solely by 
said first party, which files are executable files, 

40 In the sense that, when referenced, they operate 
on permissible data in said memory, and a pass- 
word file that is accessible only said first party 
gaining access to said executable file, a method 
for installing capability for a second party to pro- 

45 vide service to a holder of the smartcard, conn- 
prising the steps of: 

said holder assisting in establishing com- 
munlcatton between the smartcard and said first 
party; 

50 executing a log- In protocol between the 

smartcard and said first party, employing the 
data contained in said password file; 

communicating to said first party a re- 
quest for installation of a service capability on 
55 said smartcard for said second party; 

said first party establishing a user pass- 
word file In said smartcard, with said user pass- 
word file arranged to form part of said tree-like 
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structure; 

said first party inserting data into said user 
password file; and 

said first party changing file attributes of 
said user password file to make it accessible only 
to said second party. 

4. The method of daim 3 further comprising a step 
of informing said second party of the data stored 
in the user password file. 

5. The method of daim 3 further comprising a step, 
executed by said first party following said step of 
communicating to said first party a request for in- 
stallation , of confirming with said second party 
that the request for installation of service should 
be fulfilled. 

6. The method of claim 3 wherein said communica- 
tion is employing a telecommunication network. 

7. A method for a party to communicate with a per- 
sonal information device comprising the steps of: 

the personal information device authenti- 
cating the party through a challenge-response 
sequence; and 

the party authenticating the personal in- 
formation device through a challenge-response 
sequence. 

8. The method of daim 7 in which the step of the 
party authenticating the personal information de- 
vice precedes the step of the personal informa- 
tion device authenticating the party. 

9. The method of daim 7 further comprising a step 
of a holder of the personal information device be- 
ing authenticated to the personal information de- 
vice through a challenge-response sequence. 

10. The method of claim 7 where the step of the per- 
sonal information device authenticating the party 
is incomplete when the step of the party authen- 
ticating the personal identification device is com- 
menced. 



the step of the party authenticating the 
personal information device comprises the steps 
of: 

the party sending a challenge that in- 
5 eludes a second data string; 

the personal Information device encrypt- 
ing the second data string and sending the en- 
crypted second data string to the party, where 
the encryption key used for encrypting the sec- 
10 ond data string is pre-stored in the personal infor- 
mation device; and 

the party confirming the authenticity of the 
personal information device by virtue of the en- 
cryption key used to encrypt the second data 
15 string; and 

the party authenticating the personal in- 
formation device by virtue of the encryption key 
used to encrypt the second data string. 

20 12. The method of daim 11 where the first and the 
second data strings comprise random sequenc- 
es. 

13. The method of claim 11 where the first and the 
25 second encryption keys are the same. 
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11. The method of claim 7 where the step of the per- 
sonal information device authenticating the party 
comprises the steps of: 

the personal information device sending a so 
challenge that indude ID information and a first 
data string; 

the party encrypting the first data string 
and sending the encrypted string to the personal 
information device, where the key used to en- 55 
crypt the first data string Is based on the ID infor- 
mation sent by the personal information device; 
and 
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